I propose this as a more conservative way to resolve #690. At least this will make clear to the end user what the problem is. Given that the only way we know of so far that one can stumble into generating a truncated patch like this is manually editing it in an editor with trim-on-save behaviour, it should usually be no big deal for an end user to fix the problem after seeing the error message.

Alternatives considered but that I don't really like:

• Making the default behaviour really liberal, like that of Unix patch. Trouble is this behaviour is arbitrary, surprising, and could easily hide more meaningful corruption of patches.
• Adding a strict mode controlled by a boolean option. Doesn't seem worth the extra API complexity to solve a problem that will only affect people who are manually editing patches.

The only further angle for improving the state of the world I have considered was to see if anything can be reasonably changed in editors. In an editor that has trim-on-save enabled by default and also supports syntax-specific settings (and has some such settings configured by default), trim-on-save behaviour should probably be disabled by default for patch files.

Except in my current editor, Zed, that's already the case; default settings contain:

    "Diff": {
      "show_edit_predictions": false,
      "remove_trailing_whitespace_on_save": false,
      "ensure_final_newline_on_save": false,
    },

and I think VSCode has trim-on-save off by default globally.

So I reckon the best I can do is just this. Commentary welcome.